Hadoop2.xアーキテクチャの話
こんにちは、小澤です。 今回はHadoopの基本的な話をしたいと思います。
HadoopといえばMapReduce(以下MR)というイメージが今でも強い方も多いかと思います。これは、Hadoop界隈では有名なオライリーの象本と呼ばれる本も日本語版では1.x系が主流だった時のものしか出版されていなかったり、MRを隠蔽して使えるようなエコシステムが充実していることもあるでしょう。 今回は2.x系以降のYARNを含めた全体的なアーキテクチャについて解説させていただきます。
概要的内容となるため、ソースコードレベルで詳細を追うと正確ではない部分もあるかもしれませんが、今回はわかりやすさ重視での説明とさせていただきます。
Hadoop2.xを構成するコンポーネント
- HDFS
- YARN
- MRなど
の3つの構成として考えるのがわかりやすいでしょう。 上から順に、データを保持しておくためのコンポーネント、リソース割り当てのためのコンポーネント、処理を実行するためのコンポーネントというイメージとなります。
これらについて、個別に見ていきましょう。
HDFS
ビッグデータ処理を行うために重要となる、データを蓄えておくファイルシステムがHDFSとなります。 NameNodeと呼ばれるファイルシステムのツリーなどを管理するコンポーネントと実際のデータを保持するDataNodeとに分かれます。
HDFSはビッグデータを分散処理基盤上で扱いやすくするため、通常のファイルシステムとはことなる仕組みがいくつか存在しています。
まず第1の特徴として、HDFSはデータ処理を行うコンポーネントと独立して存在しているものではありません。 こうすることで、可能な限り、実際にデータを持っているノードが処理を担当することで、ネットワークをまたいでのデータ転送を最小限にとどめることが可能になります。
第2の特徴として、データの追記ができません。 (ただし、最近ではその限りではない)
なぜこうなっているかは、分散処理環境におけるバッチ処理でのデータ分析を考えてもらうとイメージしやすいかと思いますが、
- バッチ処理の対象となる単位でまとまってデータを追加できれば良い
- 1ノードあたりで処理する単位でデータがまとまっていれば良い
- トランザクション単位での細かい追加・削除は発生しない
といった特性があるため、不要な機能を省くとともに誤ってそういった処理が発生しないことを保証するのにも役立つでしょう。
最後の特徴としてレプリケーションが挙げられます。 HDFS上ではデータを複製して3箇所で同じデータを保持しています。 そのため、元のデータサイズに対して3倍のディスクサイズを使用しますが、こうすることで冗長性を持たせ、データロストの確率を下げています。
YARN
Yet Another Resource Negotiatorの頭文字をとってYARNとなっております。 これはどういうことかというと、1.x系がMRの処理に特化したフレームワークであったのに対し、2.x系ではそれ以外の分散処理方法もサポートしようという枠組みで生まれたものになります。
実際にこの仕組みのおかげでMRのみならず、TezやSparkがHadoopの分散処理基盤を利用して実行可能になっています。
この仕組みでYARNはクラスタ上の各ノードのリソース(CPU, メモリなど)の空き状況ResourceManager(以下RM)というコンポーネントが管理しており、各ノードにあるNodeManagerと呼ばれるコンポーネントとやり取りをして各ノードでのリソースの利用状況を把握しています。 新たにジョブを実行する際に適切にそれらの資源を分け与えることが可能となります。
MRなど
これは実際にジョブを実行するための枠組みとなります。 MRであれば、Map処理を行うのに必要なリソース、Reduce処理を行うのに必要なリソースといったものを処理に利用するデータサイズなどに応じて確保します。
ジョブが投入されるとApplicationMaster(以下AM)と呼ばれるノードがまず立ち上がり、AMが処理に必要なリソースをRMに要求します。 リソースが確保されると、それを使って実際の処理が行われることになります。 この時、どのような処理を実行するかは、AMに任されるため、実際にはMapReduceである必要がないという仕組みになっているがHadoop2.xにおける特徴となります。 そのため、YARNの項目でもあげたTezやSparkなどがHadoop上で動くという仕組みになっています。
Hadoop1.x系との違い
1.x系についての解説予定はないので、ざっくりとしたイメージとしてアーキテクチャを紹介します。 1.x系においては、JobTrackerと呼ばれるコンポーネントが、RMとMRに特化したAMの両方を担っているようなイメージとなります。 そのため、MR以外のジョブを実行することはできず、リソースはMap用、Reduce用といった感じで管理されています。
エコシステム
Hadoop上で分散処理を実現するためにはMRなどの独自のフレームワークに則った方法で記述するなどが必要になります。 そのため、プログラミングを専門としていないデータ分析担当者などにとってはとっつきづらいものとなっています。
そのため、Hive(SQL風の言語で記述)、Pig(独自言語で記述)などより抽象的なレイヤで処理フローを実装するためのエコシステムが存在しています。
これらについては、個々が一つのテーマとなるくらいのものとなりますので、今回は詳細は割愛させていただきます。
おわりに
いかがだったでしょうか? 今後需要がありましたら、MRを利用したジョブの具体的な実装方法やエコシステムに関する内容も書かせていただこうかと考えております。
今後とも引き続きよろしくお願いします。